OpenDoc 1.0.1 is a minor revision of OpenDoc 1.0 intended primarily to fix localization and memory utilization problems. 1.0.1 is an optional upgrade except in countries where it is being distrbuted as the initial licenseable release of OpenDoc. Developers are strongly encouraged to develop and test under 1.0.1, since it provides a more stringent test of part correctness and permits testing of the part unloading facility.
OpenDoc 1.0.1 and Cyberdog
There is a known conflict between OpenDoc 1.0.1 and the Alpha and Beta1 releases of Cyberdog. The problem is scheduled to be fixed in the Beta2 release of Cyberdog. Until this release is available, Cyberdog can be run only under OpenDoc 1.0.
(Having Cyberdog part editors, stationery and documents installed on a system running OpenDoc 1.0.1 will not in itself cause problems — you will experience difficulties only if you actually run Cyberdog parts with 1.0.1 installed. Once you install OpenDoc 1.0.1, you can reinstall OpenDoc 1.0 if you need to run the early versions of Cyberdog, or you can wait for Cyberdog B2 to become available.)
Changes since 1.0
Summary of the significant changes from OpenDoc 1.0 to OpenDoc 1.0.1:
• now reads non-English 'aete' resources
• smaller code size of 68K version
• various bugs in Editor Setup addressed
• Editor Setup is no longer modal
• part libraries unloaded from memory when no longer needed
• various bugs in Document Info and Part Info addressed
• OpenDoc splash screen is now shown only once per day
• Editor substitution dialog no longer displayed in background (caused hang)
New known issues
• Cyberdog (through B1) crashes with 1.0.1. To be fixed in Cyberdog B2.
• Editor Setup doesn't like having the contents of the Editors folder changed while it's up
(this was masked previously because Editor Setup was modal in previous releases).
New information for developers
• Part libraries are now unloaded from memory when they are no longer in use — that is, when their reference counts reach zero. To support this feature properly your part should include a CFMTerminate function as well as a CFMInit function:
extern "C" pascal void MyPartCFMTerminate()
{
// The library is being unloaded from memory, so close our
// resource fork.
CloseLibraryResources();
}
This function is specified to your linker in a way analogous to the CFMInit function: with "-term" in the MPW linker command line, or in the Linker panel of MetroWerks Preferences. It is unsupported in the Symantec environment at the time of this writing
• Because part editors previously were not unloaded, some part reference counting errors could go undetected in version 1.0. Parts should be retested to be sure they work correctly under 1.0.1. In particular, parts must be careful that their reference counts are correct and do not inadvertently reach zero, and should be diligent about cleaning up after themselves in their ReleaseAll methods.
• Due to a problem in MetroNub, you cannot target documents for debugging with MW Debug/MacOS 1.4. when using OpenDoc 1.0.1. The 1.4.1 updater fixes the problem. It's available from the MeterWerks web site at www.metrowerks.com.
• PowerMac DebugServices 2.0F1 tends to cause system hangs when debugging under OpenDoc 1.0.1. Other DebugServices versions appear to work well. (Version 2.0, which works, is on the OpenDoc Developer Release 4 CD.)
• If a part editor has been built using a -vercur linker argument that differs from its version resource, then OpenDoc will be unable to link to the library at runtime. OpenDoc 1.0 failed gracefully in this situation, but under OpenDoc 1.0.1 the error alert won't go away and the system must be rebooted. Note: this is a problem for part developers only. End users will never see it unless you ship a part that you have never successfully run on your own system.
Existing known issues
These issues exist in both OpenDoc 1.0 and OpenDoc 1.0.1, but were not previously documented. This is not a comprehensive list of OpenDoc bugs, but, combined with the "DR4 Known Problems" document issued with OpenDoc 1.0, lists some things that a user or developer is most likely to have trouble with when working with parts.
OpenDoc General
• OpenDoc allows you to create a document by choosing 'New' from the Document menu of an existing document. The new document, however, can't be saved to a different volume from the existing document. The workaround is to close and reopen the document.
• If you create a document by choosing 'New' and attempt to save it to a different volume, it will leave a temporary file behind in the same folder as the originating document. If you choose 'New' again, another temporary file with the same name will be created in the same folder.
• When displaying editor icons (as in Document Info), only the System volume's desktop database is searched for the icon to display.
OpenDoc Clipboard
• If a part promises content including embedded frames to the clipboard, content in those embedded frames could be modified before the promise is fulfilled, causing the promise to be fulfilled with content different than intended.
OpenDoc Linking
• Various annotation properties, including the kODPropProxyFrame property that signifies the presence of and provides a reference to a single embedded frame, are lost when creating or updating a cross document link. The embedded source content will either be merged, or embedded in a default frame provided at the destination.
OpenDoc Drag and Drop
• The HI spec says that you can create a link by dragging an edition file into a container. If you do, you get a Paste As dialog, but linking is disabled.
• When a document is open but has never been saved, a visible document file is created in the Finder. If this file is dragged into a container, it is bound to the editor of last resort instead of to the document's editor.
• If a cross-document drag is undone, and another drag is attempted from the source document while it is in the background, the system will hang for exactly one minute.
OpenDoc Layout
• When dragging an embedded frame between two parts in the same document, OpenDoc reuses the ODFrame. If the destination modifies the frame and then the move is undone, the source part can get back a frame that is not the same as before.
OpenDoc Scripting
• Scripts that use the clause "every part of every part" cause refcounting problems when the document is closed.
• Object marking is currently broken. It appears that the wrong context is being used in making marking decisions.
OpenDoc Document Shell
• When the document shell receives a Quit AppleEvent it displays a Save/Don't Save/Cancel alert, but won't take Cancel for an answer.
• The document shell will enter an infinite loop if there are documents open in the process with no visible windows.
• Only the first code fragment in a shell plug-in is searched for an entry point.
OpenDoc Storage
• If a non-persistent frame is purged (due to zero refcount) and later accessed by ID, the storage system will crash.
OpenDoc User Interface
• Calling ODMenuBar::SetItemText and passing in an IText whose script code is smSystemScript (not smRoman or whatever the real system script is) causes the item's command key to be lost.
• ODWindow::GetFacetUnderPoint fails to find facets which are in subframes of a selected frame.
• If a part creates a window and registers it with the WindowState, but never calls window->Open(ev), this window will probably cause a crash when OpenDoc is switched to the background.
• ODDispatcher::CheckFacetUnderMouse crashes if thePort is not set to a valid port.
• There are quite a few methods that expect a part wrapper as an argument and will crash if they receive a real part instead.
• When a part's UndoAction or RedoAction is called, the ActionData byte-array passed in mistakenly has the length field set to zero. It will have the correct contents, however.
• If WindowShade is used to collapse a document's window and the document is saved while in this state, it will reopen with an invisible zero-sized window.
• There is sometimes a problem selecting (as opposed to activating) an embedded part which contains subframes.
OpenDoc Utilities
• The '&' operator is not overridden in TempObjs, so taking the address of a TempObj returns the address of the TempObj itself rather than the object address encapsulated in it.
• The Crawl utility does not support the Metrowerks 68K compiler correctly, so that calls to WARN() cause a crash.
• ODSetITextProp in StdTypIO has an error that allows mutiple values stored for the same property to get out of sync. The IntlText value will be written only if the script code is smRoman and the language code is langEnglish. If this is not the case and an IntlText value already exists, it will be left unchanged rather than updated or deleted.
• TempODTypeListIterator methods return an ODType value which is not a copy, and must not be disposed (unlike ODTypeListIterator methods, which return an ODType value that must be disposed). The documentation has not been clear on this point.
